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REMARKS 

The Office examined claims 1-17 and rejected claims 10-17. 
With this paper, reconsideration is requested. 

Claim 10 is rejected under 35 USC §112, first paragraph. 
The Office asserts that "the means in the claim lack an 
equivalent structure description in the specification." 

Claims 10-17 are rejected under 35 USC §101, for allegedly 
not being directed to statutory subject matter. 

The Office responds to applicant's arguments by disagreeing 

that : 

a) the application program interface (API) described in the 
specification is an " equivalent structure description" to the 
means of claim 10 (and gives no reason for disagreeing except 
that "the application program interface itself does not have a 
corresponding structure description in the specification in 
either of the forms described"); 

b) those skilled in the art would understand the API to be 
software loaded for execution in a process, or alternately, an 
application specific (integrated) circuit (and again gives no 
reason for disagreeing except that "the application program 
interface itself does not have a corresponding structure 
description in the specification in either of the forms 
described) ; 

c) the server of claims 11 and 13-17 would be understood by 
those skilled in the art to be hardware operating according to 
software (asserting that it could be "just software alone in some 
instances" and justifying the rejection by noting simply that 
"there is no description in the specification to support this 
statement" ) ; and 
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d) the user equipment terminal of claim 12 is described in 
the specification to be various devices such as a cellular phone, 
laptop with mobile terminal, or a mobile router (and gives no 
reason for disagreeing) ; 

e) the API must be software hosted for execution by- 
hardware, because software alone cannot response to an input (and 
again gives no reason for disagreeing except for arguing that 
"nowhere in the specification is there an indication that the API 
must be software executed by hardware") . 

The Office concludes with the statement: 

In light of a lack of evidence to support the 
conclusion that servers and API are understood to be 
software executed by hardware, the prior rejections under 35 
USC §101 Sc 112 are upheld. 

Applicant provides here evidence that the recited servers 
and application program interfaces would be understood by anyone 
skilled in the art to be software executed on hardware. 
Applicant nonetheless urges the Office to consider that the 
requirement of providing evidence is less than a frugal use of 
the adjudicatorial resources of the Office, and imposes a burden 
on the applicant that is unusual and puzzling, in view of the 
fairly indisputable assertions made by applicant. 

The recited API is software executed by hardware 

Claim 12 recites "a user equipment terminal, comprising: a 
first application program interface ... and a second application 
program interface ... , " and so it is plain to see that whatever 
the application programming interfaces (APIs) are, they are 
something included in a UE, and they respond to inputs and 
provide outputs. This is characteristic of software executed by 
hardware, and so serves as evidence that, as used in the claims, 
an API is software executed by hardware. 
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But further in the way of evidence, the following sources 
available over the Internet provide an explanation of what is 
meant, formally, by the term API or "application programming 
interface. " 

From Wikipedia, at en.wikipedia . org/wiki/API , 

An application programming interface (API) is a source 
code interface that a computer system or program library 
provides in order to support requests for services to be 
made of it by a computer program. 



The software that provides the functionality described 
by an API is said to be an implementation of the API. ... 



The term API is used in two related senses: 

* A coherent interface consisting of several classes or 
several sets of related functions or procedures. 

* A single entry point such as a method, function or 
procedure. 

From the Gordano knowledge base, at www.gordano.com/kb.htm?g=234, 

An API or Application Programming Interface, allows 
programmers to access the functionality of a pre-built 
software module through well-defined data structures and 
subroutine calls. 

From SearchExchange.com, a resource for Microsoft Exchange 
"professionals , " at : 

http: //searchexchange. techtarget . com/sDef inition/0 , 290660, sid43_g 
ci213778, 00. html, 

An application program interface (API - and sometimes 
spelled application programming interface) is the specific 
method prescribed by a computer operating system or by an 
application program by which a programmer writing an 
application program can make requests of the operating 
system or another application. 

As is clear from the above, the term API can refer to 
software, and applicant presumes that the Office does concede 
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that software is executed by hardware. The term API can also 
refer to the method by which one computer program requests the 
services of another, i.e. the rules a programmer must follow in 
coding one application in order to request the services of 
another. Applicant respectfully submits, though, that it is 
plain to see that as used in the application, API is intended to 
refer to actual software, i.e. to an implementation of an API. 
The description at page 14, beginning line 1, provides that: 

The invention is practiced by a digital communication 
system and a UE communicating via such a communication 
system. The UE can be any of several kinds. In TS 
33.203, the UE is a mobile terminal MT (cellular 
phone) . However, other kinds of UEs can advantageously 
practice the invention as well, including UEs without 
an integral MT component, but attached to an external 
MT, such as a laptop computer attached to a MT or to a 
mobile router, or other devices that communicate with a 
MT. It is important to understand that the list of 
devices given here is not intended to be exhaustive. 
In addition, some devices will not implement the 
complete functionality provided by the invention, but 
will support only a few services/ applications provided 
by the IMS. 

Since the invention is, in claim 12, "a user equipment 
terminal, comprising: a first application program interface ... and 
a second application program interface ... , " applicant submits 
that it is beyond question that API is used in the application as 
an actual implementation, i.e. software, executed by a processor 
in a UE (such as a laptop computer or cell phone) , as opposed to 
rules a programmer must follow in coding one application in order 
to request the services of another. The latter interpretation is 
nonsensical in the context of the invention as set out above. As 
illustrative of this interpretation, at page 11, at line 9, the 
application explains: 

Once the P-CSCF receives SMS, in a step 34 it parses 
the information and provides from the parsed 
information an Security Policy Database (SPD) entry (or 
entries) (i.e. a policy entry), and inserts the SPD 
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entry (or entries) into its SPD through a * Security 
Policy API" (API being the acronym for Application 
Program Interface) , which in the Symbian implementation 
is named Secpol API, but which in other implementations 
could have other names . 

So here the P-CSCF, i.e. the proxy call state control function, 
uses an API to interface with a security policy database. As 
anyone skilled in the art would know, a P-CSCF is not a person, 
nor is it software not in a form executable by a processor, i.e. 
e.g. on paper; it is software executed by hardware, i.e. it is 
software stored so at to be executable by a processor. This 
software then uses an API to interface with other software, and 
so the API which must therefore be software. Thus, applicant is 
using the term "API" to indicate a software module, i.e. software 
executed by hardware, that is used for interfacing with another 
application. 

Further, applicant respectfully submits that instead of 
reciting first and second API's, claim 12 might have used any 
other label to refer to the software executed by hardware that is 
clearly intended by the claim language. Although API is nicely 
suggestive of functionality indicated by the recited claim 
elements, even w a first module" and w a second module" would 
suffice. The functionality and actual structure is recited by 
virtue of the recitation of the inputs and outputs, i.e. the 
claim elements are recited as responding to the certain inputs by 
providing the certain outputs, and thus particular processing is 
recited, i.e. the processing required to provide the outputs 
given the inputs. This processing is structure, and is clearly 
provided by software executed by software. Applicant understands 
and believes that the Office will concede that disclosure of the 
actual software executed by hardware is not required for 
enablement, i.e. in order to disclose structure. 
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Applicant asserts also that as anyone skilled in the art 
would understand, any software may be provided by an ASIC, i.e. 
the effect of software executed on hardware (a digital processor) 
can be provided instead by an ASIC. Thus, all assertions in the 
above to the effect that an API is software executed by hardware 
must be understood to encompass an assertion that an API could 
include one or more ASICs or be provided entirely as one or more 
ASICs. Also, as anyone skilled in the art would know, any 
software can be provided as firmware, i.e. computer chips that 
have data or programs recorded on them, chips such as ROMs (read- 
only memory) , PROMs (programmable read-only memory) , or EPROMs 
(erasable programmable read-only memory) . 

The recited server is software executed by hardware (or hardware 
executing software) . 

The server of claims 11 and 13-17 is recited as "a home 
subscriber server." 

From Wikipedia, at en.wikipedia.org/wiki/ 
IP_Multimedia_Subsystem, 

The HSS (Home Subscriber Server or User Profile Server 
Function UPSF) is the master user database that 
supports the IMS network entities that are actually 
handling the calls/sessions. It contains the 
subscription-related information (user profiles), 
performs authentication and authorization of the user, 
and can provide information about the physical location 
of user . It's similar to the GSM HLR and AUC. 
[Emphasis added.] 

So for example, the HSS accepts an input from a UE that is a 
request to authenticate the identity of the UE, and to do so, as 
is commonly known, engages in various transactions with the UE in 
the course of authenticating the UE. Thus, the recited server is 
understood as a thing that processes inputs and provides outputs. 
It must thus be understood as software executed by hardware, or 
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else as hardware operative according to software, either one of 
which is statutory. It cannot, though, be understood as merely 
software, i.e. as e.g. a paper copy of software and so not in a 
form executable by a processor. 

The term * server" as used in computing in general is defined 
in Wikipedia, at en.wikipedia.org/wiki/Server, as 

a computer that provides services to other computers, 
or the software that runs on it also like the internet 
sites like Google and Yahoo. 



Other interpretations are possible and the claims should still be 
allowed. 

Even if the recited servers and application programming 
interfaces could be interpreted as merely software, the Office 
can allow claims 10-17 because the recited language at least 
encompasses statutory subject matter. The MPEP at 2164.08(b), 
"Inoperative Subject Matter," provides: 

The presence of inoperative embodiments within the 
scope of a claim does not necessarily render a claim 
nonenabled. The standard is whether a skilled person 
could determine which embodiments that were conceived, 
but not yet made, would be inoperative or operative 
with expenditure of no more effort than is normally 
required in the art. Atlas Powder Co. v. E.I. du Pont 
de Nemours & Co., 750 F.2d 1569, 1577, 224 USPQ 409, 
414 (Fed. Cir. 1984) (prophetic examples do not make 
the disclosure nonenabling) . 

Although not squarely on point in regard to the issues at hand, 
applicant respectfully submits that the MPEP at 2164.08(b) does 
nonetheless strongly suggest that even though unfavorable 
interpretations of the claims are possible, if the claim language 
can be interpreted so as to indicate patentable subject matter, 
as is the case here for the reasons indicated above, the claims 
can be allowed. 
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Accordingly, in view of the above evidence, applicant 
respectfully requests that all the rejections under 35 USC §101 
and §112, first paragraph, be withdrawn. 

Conclusion 

For all the foregoing reasons it is believed that all of the 
claims of the application are in condition for allowance and 
their passage to issue is earnestly solicited. 
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